前言

嗨，我是Hogan
目前在經營自己的自媒體 hogan.tech
主要分享一些有關於程式碼、軟體和科技業經驗分享
有興趣的讀者可以進一步關注我，進而獲得更多資訊唷！

未來文章一併更新於此網站 Hogan.B Lab
並且包含多語系 繁體中文、英文、日文、簡體中文
觀看分類：React 白話文運動、其他系列

如果想要快速查找其他文章請點選目錄

成立 hogan.tech 的初衷是
希望每個正在這條路上探索的人，
都可以透過 Hogan.tech 嘗試進入程式領域。

前一篇講解Hook系列的最後一個Hook - useReducer

1. useState 的寫法
2. useResucer 的寫法
3. class component 的寫法

這一篇會與大家介紹另一個狀態管理的概念 Flux

1. Flux 起源
2. Flux 概念與組成

Flux 起源

如果往往前追溯 Flux 概念的話，可以找到此2014年開發者大會的 影片

我自己本身也有實際看完影片才寫這篇文章的

Flux 與React 一樣，是由Facebook團隊提出的一個狀態管理概念，在當時比較的對象為MVC 架構

MVC 當時是滿多大型商業網站的主流，不過本身存在一些問題，包含如果系統越大越複雜，則整個資料流就會錯綜複雜

那麼Flux 希望可以做到哪些事情呢？

1. 使用明確的資料而非衍生的資料
2. 將資料與View去做分離

Flux 希望可以帶來的好處？

1. 有更多實質意義的單元測試
2. 提升資料的一致性

以下兩張圖為當時開發者大會所放上的圖例，當然MVC 架構正常來說不會如此錯綜複雜

透過這樣的對比可以發現Flux 相較於MVC 來說簡潔不少，那接下來就要講解一下Flux的概念

Flux 概念與組成

MVC

MVC 本身為雙向資料流，由 Model、View、Controller 所組成，每個角色都有各自需要完成的任務

不過當我們功能越多，提供的Model、View、Controller關聯越複雜時，很容易忘了誰與誰是有關聯的

這也會讓整體架構相對發散且難以維護與測試

Flux

Flux 本身是一個單項資料流，透過Action、Dispatcher、Store、View 所組成，相較於MVC 定義三種不同角色的關係，Flux 比較像是清楚定義資料進行的方式。

Flux 組成

• Actions
  • Helper methods that facilitate passing data to the Dispatcher
• Dispatcher
  • Receives actions and broadcasts payloads to registered callbacks
• Stores
  • Containers for application state & logic that have callbacks registered to the dispatcher
• Controller Views&View
  • React Components that grab the state from Stores and pass it down via props to child components.

Actions：規範改變資料的動作

Dispatcher：將目前發生的行為，告知已註冊的Store

Stores：存放資料以及邏輯，並且只提供call back funciton 來註冊 dispatcher

Views：根據Store狀態，渲染UI 以及監聽使用者的操作

這裡附上一張自己用Miro 畫出來的流程圖

在Flux 架構上，如果需要修改Store，則需要透過已設定好的流程來去做改變，而非直接去做修改

舉例來說，我們可以透過Clinet 端的event 去送出Custom event，再由 Custom event 去修改Store裡面的狀態

結語

這一篇介紹另一個狀態管理的概念Flux

相較於前幾篇，這篇沒有程式碼反而是與概念相關的流程圖

如果有任何建議與疑問也歡迎留言！

如果喜歡此系列文章，請不吝於按下喜歡及分享，讓更多人看到唷～